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DETAILED ACTION 

1 . This action is responsive to the Applicant's response filed 4/07/2005. 

As indicated in Applicant's response, claim 1 has been amended. Claims 1-4 are pending 
in the office action. 

Claim Rejections - 35 USC § 103 

2. The following is a quotation of 35 U.S.C 103(a) which forms the basis for all 
obviousness rejections set forth in this Office action: 

(a) A patent may not be obtained though the invention is not identically disclosed or described as set forth in 
section 102 of this title, if the differences between the subject matter sought to be patented and the prior art are 
such that the subject matter as a whole would have been obvious at the time the invention was made to a person 
having ordinary skill in the art to which said subject matter pertains. Patentability shall not be negatived by the 
manner in which the invention was made. 

3. Claims 1-4 are rejected under 35 U.S.C. 103(a) as being unpatentable over Beausoliel et 
al., USPN: 5,551,013 (hereinafter Beausoliel) in view of Austin et al., USPN: 4,885,684 ( 
hereinafter Austin); and further in view of Baker et al, USPN: 5,701,502 (hereinafter Baker). 

As per claim 1, Beausoliel discloses a emulation engine comprised of a plurality of 
modules, a work station, and a bus for transferring data between the work station and said 
modules (Fig. 1,8), each of such modules including a plurality of processors and a module main 
memory accessible for data transfers during an emulation by each of such processors (e.g. col. 3, 
line 55-65; col. 5, lines 32-35; Fig. 3A-B), each of such processors having a control store to store 
a programmable sequence of emulation steps that define logic states for its processor (e.g. col. 4, 
lines 1-5; col. 6, lines 2-10; Fig. 9 A, 1 1 A), a method to allow data transfers between such 
module main memory unit and work station without interrupting an in-progress emulation (non- 
blocking- col. 8, lines 16-56; Fig. 5,7), comprising: 
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compiling said programmable sequence of emulation steps to include, in at least one step, 
a blocking code, when the step is read from the control store (e.g. col. 10, line 64 to col. 1 1, line 
29; Control Store - col. 5, line 39 to col. 6, line 18; Figs. 2-3 ), as a disable command between 
the plurality of said processors and main memory unit ( e.g. active, inactive - col. 6, lines 14-27, 
28-59 ); 

decoding said blocking code (e.g. col. 12, Table 1- Note: decoding is inherent to 
encoding instructions; Fig. 2a-b; Fig. 3a-b - Note: control word field/bit extraction is equivalent 
to decoding instructions code); and 

transferring data between said work station and module main memory (e.g. input to 
target system, emulation support facility- col. 3, lines 28-37 ; workstation - Fig. 8 - Note: 
workstation is equivalent to host computer coordinating the support facilities functions operable 
on the processor modules, e.g. data or instructions transfer) 

But Beausoliel does not specify a maintenance bus for transferring data between the 
workstation and processor modules. However, Beausoliel discloses latches and multiplexers to 
control data flow into or out of a given processor execution in the emulation logic; and path 
control bits multiplexing and changes for allowing concurrent data connection to support 
facilities in the emulation environment (e.g. col. 3, lines 28-37; col. 8, lines 16-56; Fig. 1, 2A, 
3A-B) as well as recompiling of code modification as a result of errors (col. 10, lines 37-43). In 
view of the teaching by Beausoliel to address errors and to maintain support the emulation 
changes in code, to have facilities to control data flow from a processor, a need to maintain the 
memory is suggested. Austin, in a network of processing units simulation environment with 
emulation, programmability/debug and interprocessor communication/scheduling and 
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management support (see cols. 4-13; col. 17, lines 22-46) analogous to that of the emulating 
network of Beausoliel such as to use software program for deploying/supporting the functionality 
of the distributed data processing, discloses a maintenance bus for both the processing elements 
and for the supervisor unit (e.g. EMB and TMbus - col. 6, lines 4-26) for update storage 
operations, and other off-line functions. In view of the suggested teachings from Beausoliel 9 s 
and Austin's from above, it would have been obvious for one of ordinary skill in the art at the 
time the invention was made to provide a maintenance bus as taught by Austin to Beausoliel' s 
concurrent support facilities operable within the emulation execution and operations by the 
processing units of Beausoliel' s system because this would provide a specialized communicating 
channel, e.g. bus, to support the maintenance operations as suggested by Austin without affecting 
or interrupting the main data flow used by the processing units of the emulation by Beausoliel, 
thereby obviate bus/memory contention issues and enhance fault prevention, efficiency. 

Nor does Beausoliel explicitly specify that in response to decoding blocking code, 
blocking transfers between the plurality of module processors and said module main memory 
units; and transferring data between the workstation and module memory units during such 
blocking from above; that said blocking code included in a emulation step thereby allowing data 
to be transferred between said work station and said main memory; and blocking data transfers 
between said module processors and said main memory. However, Beausoliel' s disable 
command from decoding the MOP bit teaches disabling access by the processors to specific parts 
of memory. This implicitly discloses a blocking of transfer between the processors and the 
memory during an emulation step. 
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Austin, in the system for supporting and deploying distributed processors via software as 
mentioned above, discloses the use of maintenance bus to support the operations of the 
processing modules (re col. 6, lines 4-26); and teaches, via the use of LOS ( Local Operating 
System), initialization, debug and error-related suspension operations within the emulating unit 
processors and/or recovery operations using such maintenance bus (e.g. col. 7, lines 51-63; 
suspension, minimal overhead - col. 12, line 47 to col. 13, line 7; maintenance bus, alternate 
paths - col. 9, lines 3-33, 42-50). The use of maintenance facilities to allow recovery of faulty 
modules and to prevent contention of memory access during such recovery or maintenance tasks 
or the use of a protocol implemented via control bits to reject or block memory access to bus- 
connected processors or requests was a known concept as evidenced herein with Baker. Baker, 
also in an environment to use software or microcode to integrate functions of a target system 
emulating processors based on a existing processor operating system to achieve fault-tolerant 
system analogous to the integrated development network using code simulation by Baker, 
discloses a maintenance bus and halting of process communications between the faulty 
processing unit and the central operating system in response to decoding a request to handle a 
maintenance interrupt (e.g. lock-step -col. 1 19, line 4-53) and thereby invalidating of non-valid 
data transfer to memory (e.g. col. 127, lines 3-23). Hence, in view of above-mentioned 
Beausoliel's teachings on support facilities and memory code recompiling; and Austin's use of 
maintenance bus in conjunction with Baker's scheme to suspend servicing of slave processing 
units memory requests for synchronization tasks as a result of a maintenance interrupt detection 
as mentioned above, it would have been obvious for one of ordinary skill in the art at the time the 
invention was made to implement code instructions as taught by Beausoliel so that when a 
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blocking code is decoded, the transferring of data between processors and their memory units is 
blocked so that the maintenance bus is utilized in order to allow data be transferred from the 
maintenance dedicated workstation onto the main memory unit just as suggested by Austin and 
by the recovery synchronization calls by Baker for the same reasons as mentioned above in the 
rejection of the maintenance bus limitation and also because this would avoid further 
contamination/incoherency of the processor memory when external data are written to their 
memory units, i.e. synchronized maintenance process as taught by Baker so to prevent further 
damaging to a memory. 

As per claim 2, Beausoliel does not specify the step of unblocking transfers between the 
module processors memory unit when such step is sequentially decoded next after a blocking 
code step. But in view of the combined teachings by Austin and Baker's teachings on 
suspending operations upon a failure detection (Austin: col. 7, lines 51-63; suspension, minimal 
overhead - col. 12, line 47 to col. 13, line 7; maintenance bus, alternate paths - col. 9, lines 3-33, 
42-50; Baker: lock-step - col. 1 19, lines 12-24) as mentioned above, it would have also been 
obvious to add the step of unblocking after a decoded step of blocking has been completed to 
Beausoliel' s repetitive emulation process because the motivation would be that once the 
maintenance steps as suggested by Austin are completed, it. would be necessary to resume the 
data transfer and communication between the processors and their memory unit or bus system in 
Beausoliel 5 s system in order to proceed on with the rest of the emulation. 

As per claim 3, Beausoliel discloses a repetitive cycle in decoding and emulating the 
program code (e.g. col. 12, lines 5-13) but fails to specify that the transferring of data step 
between module memory and workstation is repetitive. But in view of the rejection of such data 
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transferring step as addressed in claim 1, the repetition of such data transfer would be inferred 
from the combined teachings by Beausoliel (repetitive emulation decoding) and Austin 
combined with Baker (maintenance bus, LOS, suspension and initialization operations) and the 
rejection as set forth above. 

As per claim 4, Beausoliel discloses a repetitive cycle in decoding and emulating the 
program code (e.g. col. 12, lines 5-13) but fails to specify that the transferring of data step 
between modules memory units and workstation being followed by an unblocking step is 
repetitive. This limitation corresponds to the same limitation of claim 3 above; hence, in view 
of the combined teachings by Austin/Beausoliel/Baker and the rejection as set forth in claims 2, 
and 3 above, this limitation would have been obvious because of the rationale as set forth therein. 

Response to Arguments 
4. Applicant's arguments submitted 4/7/2005 with respect to claims 1-4 have been 
considered are not persuasive and in that respect, deserve some counter arguments. 
(A) Applicants have submitted that Beausoliel' s MOP bit does not 'block data transfers 
between said plurality . . . processors . . . memory' and does not teach 'allow data to be transferred 

between work station ... main memory' ( Appl. Rmks, pg. 5, last 2 para); that said MOP 

bit is not intended to allow such data transfer and that it simply controls whether a module 
processor will emulate a logic function or a memory function. In col. 10, line 64 to col. 1 1, 
Beausoliel' s disabling command reads on denying if not blocking access to certain memory part 
that would otherwise be accessible had the control word in the control store be different. Thus, 
the limitation referred to as 'blocking or allowing data transfer' does not amount to a particular 
blocking scheme because as interpreted and used in the rejection, not accessing a memory for 
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some memory type of operation as taught by Beausoliel clearly reads on not being able to 
perform data transfers to and from said memory module during any given emulation step 
involving the processors of context. As for 'said blocking code and . . . blocking transfers 
between the plurality of . . . processors and thereby allowing . . . workstation . . . main memory', it 
is noted that the whole phrase as claimed entails that one processor is allowed to effect data 
between the main memory, not the rest of the processors which are being emulated in a particular 
emulation code execution stage. The rejection has explained that code being decoded during an 
emulation step is disclosed. Complementing to the understanding that one processor access is 
allowed at the expense of the rest of the system being blocked from using a common memory, 
the rejection has mentioned Beausoliel 5 s need for such common memory modification and how 
such need require supporting facilities and maintenance work. Austin is therefore brought in to 
provide such maintenance bus, and Baker's special error readjusting commands are used in order 
to fulfill Beausoliel' s need to maintain a memory during different emulation stages where code 
need to be recompiled to avert errors. The claim does not describe in more precise terms so 
enabling how such data transfer as recited would distinguish over the combined teachings by 
Austin and Beausoliel in view of Baker's approach, i.e. why these teachings as put together 
would clearly fail to amount to the so-called limitation by which blocking of many processors 
and allowing only one processor to use the common memory is done. As construed by the claim, 
a maintenance bus is present in the course of stages of emulation, a bit detected so to allow only 
just one processor to access a shared memory while preventing all target processors from 
accessing it. Such bit event is interpreted as a dynamic maintenance adjustment being triggered 
via a code to allow memory to be modified by just one processing unit with the rest of the system 
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being kept off; and this is reminiscent of synchronization of shared memory by one main 
processor in a exclusive session — and this synchronization process was a known concept, the 
detection of which control code dictates that one and only one processor can modify the content 
of such shared memory, i.e. a maintenance process using an equivalent of mutual exclusion. 
Based on Beausoliel's facilities and emulation system needs to update its compiled code, the 
motivation to provide a maintenance bus as via Austin and a special code by Baker to allow a 
process to correct memory contents while keeping other processes from further damaging it has 
been evident; and the reasons why the combination would have been obvious are set forth in the 
rejection. 

(B) Applicants have submitted that Austin and Baker in view of Beausoliel's emulation 
method relate to completely different and unrelated technologies (Appl, Rmks, pg. 6, middle 
para). There is no requirements in a USC 103(a) type rejection that the references being put 
together should come from exactly analogous fields of technologies; it is a particular aspect of a 
field or methodology for which a common endeavor is targeted, and the purpose in such 
endeavor being aimed at is what is at issue for providing a obviousness rationale, not the field 
within which such common endeavor and purpose is being set. The field is scheduling and 
controlling operations of multiprocessors environment, using a common memory accessible via a 
bus; and the endeavor for which a purpose is targeted is to provide a expedient and save way to 
correct the content of such memory to prevent further damage, e.g. maintenance operation, and 
not indefinitely disrupting the operation of the multiprocessor system. A decoding of a code and 
a timely permitting of one processor to access a common memory which is to be updated while 
excluding the rest of the processors amount to specifically what is perceived from the 
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interpretation of the claimed 'maintenance bus', 'blocking code', and 'said blocking code and ... 
blocking transfers between the plurality of . . . processors and thereby allowing . . . workstation . . . 
main memory' as mentioned above. Hence, the references by providing teaching combining a 
maintenance needs (Beausoliel), a bus (Austin) and exclusive access (Baker) for memory 
corrective needs have been set forward to provide the rationale as to why the claimed limitation 
as interpreted would have been obvious, notwithstanding the non-analogous fields of 
technologies as alleged by Applicants. If the claimed invention has to be treated as a whole such 
as has been shown above via broad reasonable interpretation, the rejection as set forth has to be 
treated in light of the combined teachings from all references including the inherent or suggested 
teachings thereof. Thus, arguing that the references come from disparate fields or technologies 
amount to mere allegations without showing why the combined teachings fail to teach the 
claimed invention as interpreted; even by exposing deficient teachings in each reference taken 
individually, which would have been inconclusive in showing why these teachings fail to 
distinguish over the claimed invention. 

In short, Applicants' argument about references not being analogous is not persuasive. 
That all the references presented should come from analogous fields of endeavor is not a strict 
requirement according to current rules and procedures governing USC 103(a) rejection. It is an 
application and/or useful methodology that needs to be addressed not the environment wherein 
such methodology is being suggested or disclosed. Hence, by applying a motivation when 
combining the teachings from 3 references as set forth in the rejection, a prima facie case has 
been established; and the mere allegation that the references used come from 3 technologies does 
not amount to overcome the rationale as set forth in the rejection. 
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The claims will stand as set forth in the rejection. 



Conclusion 



5. 



Any inquiry concerning this communication or earlier communications from the 



examiner should be directed to Tuan A Vu whose telephone number is (272) 272-3735. The 
examiner can normally be reached on 8AM-4:30PM/Mon-Fri. 

If attempts to reach the examiner by telephone are unsuccessful, the examiner's 
supervisor, Kakali Chaki can be reached on (571)272-3719. 

The fax phone number for the organization where this application or proceeding is 
assigned is (571) 273-3735 ( for non-official correspondence - please consult Examiner before 
using) or 703-872-9306 ( for official correspondence) or redirected to customer service at 571- 



Any inquiry of a general nature or relating to the status of this application should be 
directed to the TC 2100 Group receptionist: 571-272-2100. 

Information regarding the status of an application may be obtained from the Patent 
Application Information Retrieval (PAIR) system. Status information for published applications 
may be obtained from either Private PAIR or Public PAIR. Status information for unpublished 
applications is available through Private PAIR only. For more information about the PAIR 
system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR 
system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). 
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